In computer and communication security applications like secured financial transactions over the Internet including online banking and online shopping, public-key cryptographic systems (PKCS) are now commonly used.
In this context, there are two types of secure information interchange relevant to this patent application. First, a recipient may need to be able to verify that a message was actually sent by the person claiming to be the sender of the message and that the message was not altered by a third party in transit. This need is met by an signature-verification system. A PKCS signature-verification system allows a sender with a (private) signature key to send a message with a digital signature created using the message and the signature key. A recipient who has the sender's (public) verification key may then use the PKCS system to validate the integrity of the message and the identity of the sender.
Second, a recipient may need to be assured that even if a third party had access to the message in transit, the message was unintelligible to the third party. This need is met by a PKCS encryption-decryption system. In this mode, a PKCS system allows a recipient with a (private) decryption key to decrypt a message from a sender that is encrypted by the sender using the recipient's (public) encryption key. In actual practice, both types of uses may be combined in a single system; alternatively, a system may use a PKCS system for one application and another type of system for the other. In this background for the specification, the exposition is made in terms of signature-verification PKCS systems, but the subject matter in the case of encryption-decryption PKCS systems is analogous.
For ease of exposition consider a pair of parties termed Alice and Bob who wish to exchange information securely. Consider specifically that Alice wishes to sign messages sent to Bob and that Bob wishes to verify the digital signatures on messages received from Alice. In a first step Alice uses a PKCS to generate a signature key (a string of symbols) and a verification key. Alice may then provide the verification key to Bob and other potential recipients of her messages. To create a signed message, Alice provides the message and her signature key to the PKCS which uses her signature key and the contents of the message to generate a digital signature. A digital signature is a string of symbols that is unique for each message and signature key. The message with the digital signature attached (signed message) is then transmitted to Bob. Bob may now use Alice's verification key and the digital signature to verify that the message is from Alice and that the message was not tampered with in transit. If Bob receives a message with a signature that is verified as Alice's by Alice's verification key, he can be very confident that the digital signature was created using Alice's signature key.
In commercial and marketplace transactions, this process is complicated by the fact that Alice may not be able to provide Bob with her verification key in a trustworthy manner, for example, if Alice is a vendor on the Internet and Bob is a remote customer. Bob may therefore be hesitant to trust a verification key that is claimed to be Alice's verification key in case he is actually communicating with and using a key from a possibly malicious party masquerading as Alice. In order to solve this problem, institutions termed certificate or validation authorities (CAs or VAs) have been created to serve as trust brokers. A party wishing to communicate with other parties securely and wishing to provide the other parties with a level of trust in the party's identity, first registers its identity and public verification key with the CA which validates the party's identity before making the public verification key available to other parties. The CA is then able to provide a certificate for each registered party including at least the name of the party, the public verification key of the party and the signature of the CA itself. Alice, for example, would register herself with a CA and Bob would obtain Alice's certificate from the CA and thereby be assured that he was indeed communicating securely with Alice by using the public verification key from Alice's certificate.
Similarly, Bob may have an signature key and a certificate associated with his corresponding verification key. If the certificate is issued by a CA that Alice trusts, then Alice can use the certificate to validate the integrity of or to verify the authorship of messages that are purportedly from Bob.
A digital certificate is thus in general a statement digitally signed by a CA binding a key-holder's name to a public verification key. A certificate may also include a label for a public verification key with a label or attribute, such as a nickname, group name, account number, photo, etc. Furthermore, a certificate may authorize a key (or all keys with a given label or name) to do something. A certificate typically specifies the issuer, the subject, a public verification key, an issue date, and an expiration date. Certificates are a useful component of an infrastructure to support digital signatures.
Certificates may become invalid. Bob may change his last name and so make his existing certificates invalid, or be fired from a company, causing a certificate in which Bob is identified as a representative of the company invalid. Alternatively, Bob's signature or decryption key may be compromised or stolen therefore making the corresponding verification or encryption key in the certificate invalid. An issuer may thus wish to “revoke” a previously-issued certificate.
Periodically-issued certificate revocation lists (CRLs) are one common approach to revoking certificates. Such lists may be published by a CA and each such list specifies what unexpired certificates have been revoked, and when the next CRL will be issued. The CRL is signed by the issuer. For example, a company might issue a weekly CRL for its employee's certificates. The possibility that a relied-upon party's certificate may have been revoked requires that another party relying upon the first party must always check to ensure that the certificate has not been listed in a recent CRL. For example, before Bob uses Alice's web site to purchase a book, Bob would ideally acquire the latest CRL from Alice's CA to ensure that the certificate that Bob believes is Alice's valid certificate has not been revoked. If Bob has a CRL that does not list a recent revocation of Alice's certificate, he may for example be communicating with a malicious agent who is masquerading as Alice after improperly acquiring Alice's signature key.